X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C73CFB.12B9E766@onstor-exch02.onstor.net>; Sat, 20 Jan 2007 17:25:45 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73CFB.12B9E766"
Content-class: urn:content-classes:message
Subject:  RE: Functional Spec : Increase the number of TCP connections - for review
Date: Sat, 20 Jan 2007 17:25:51 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0222879B@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic:  RE: Functional Spec : Increase the number of TCP connections - for review
thread-index: Acc83H7MadyOqtJqQluj02kZHxGfjAAHozGw
From: "Jonathan Goldick" <jonathan.goldick@onstor.com>
To: "Shamsudeen Jeseem" <jeseem@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>,
	"Narayan Venkat" <narayan.venkat@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73CFB.12B9E766
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

1.	Update the copyright to 2007.  Jay made a new template somewhere
with all this stuff handled.
2.	In section 1, there is a typo in the MRD link, you have an extra
space in front of "Delorean MRD-PRD-REV1-7.xls"
3.	In section 4, is Cheetah really not required?  I only ask
because the MRD mentions Nissho by name and their customers have
Cheetah(s).  Narayan, please comment.
4.	In section 4, is CLUSDB_REC_TYPE_CORE_DUMP a typo?  I'm missing
why we would put this under core dump but perhaps this relates to the
comment in section 7 about avoiding a migration; it just seems confusing
so I thought I'd ask.  Anyways, is it really required that we make this
configurable?  Perhaps it's acceptable to just detect the model number
and set the value?  If we could make this hard-wired per model number
then we could cut out a number of the tasks and make this an easier
project and test effort.  Narayan, please comment.
5.	Can we make section 7.1 its own major section since testing is
not really a sub-chapter of Migration Strategy?
6.	In section 7.1, can we add a test where we send some load, even
if it's low, across all the connections?  We need to know if the number
of Ops we can service changes dramatically if the load is spread across
a lot of connections versus our normal tests with very few connections.
7.	In section 7.1, we probably should add a statement that we are
not able to make sure that this many connections will work properly with
LinkAggregation set up.  While inn practice I would expect customers to
use something to spread such a huge load around, we just don't have the
infrastructure to simulate that number of clients in a way that
exercises LinkAggregation.  This is probably more of a test about
whether the switches actually function properly anyways.
8.	Once you get all of this working in a networking sense we need
to determine whether it works in practice with so many CIFS or NFS
connections.  If we could handle 1000 CIFS logons with Kerberos in 10
seconds(making this number up for discussion purposes) then 32K CIFS
connections is about 5 minutes and makes sense, but is 128K really
achievable and across how much time would we have to spread the initial
connects to avoid overloading the auth-agent?  There is a similar issue
for NFS mounts with non-trivial export options (NIS netgroups).  While
what you are proposing looks pretty complete from a networking (NCPU)
layer, I think we need more on the CIFS/NFS/Auth-Agent layer changes
that might be required to make such a large number of connections
actually usable.



------_=_NextPart_001_01C73CFB.12B9E766
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE> RE: Functional Spec : Increase the number of TCP connections - =
for review</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Courier =
New">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><SPAN LANG=3D"en-us"> <FONT =
SIZE=3D2 FACE=3D"Courier New">Update the copyright to 2007.&nbsp; Jay =
made a new template somewhere with all this stuff =
handled.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">In section 1, there is a typo in the =
MRD link, you have an extra space in front of &#8220;</FONT><FONT =
SIZE=3D2 FACE=3D"Courier New">Delorean MRD-PRD-REV1-7.xls</FONT><FONT =
SIZE=3D2 FACE=3D"Courier New">&#8221;</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">In section 4, is Cheetah really not =
required?&nbsp; I only ask because the MRD mentions Nissho by name and =
their customers have Cheetah(s).&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Courier =
New">Narayan, please comment.</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">In section 4, is</FONT> <FONT =
SIZE=3D2 FACE=3D"Courier New">CLUSDB_REC_TYPE_CORE_DUMP</FONT><FONT =
SIZE=3D2 FACE=3D"Courier New"> a typo?&nbsp; I'm missing why we would =
put this und</FONT><FONT SIZE=3D2 FACE=3D"Courier New">er core dump but =
perhaps this relates to the comment in section 7 about avoiding a =
migration; it just seems confusing so I thought I</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New">&#8217;</FONT><FONT SIZE=3D2 FACE=3D"Courier New">d =
ask.&nbsp; Anyways, is it really required that we make this =
configurable?&nbsp; Perhaps it</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New">&#8217;</FONT><FONT SIZE=3D2 FACE=3D"Courier New">s acceptable to =
just detect the model n</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New">u</FONT><FONT SIZE=3D2 FACE=3D"Courier New">mber and set the =
value?&nbsp; If we could make this hard-wired per model number then we =
could cut out a number of the tasks and make this an easier project and =
test effort.&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Courier New">Narayan, please =
comment.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">Can we make section 7.1 its own =
major section since testing</FONT><FONT SIZE=3D2 FACE=3D"Courier New"> =
is not really a sub-chapter of Migration Strategy?</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">6.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">In section 7.1, can we add a test =
where we send some load, even if it</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New">&#8217;</FONT><FONT SIZE=3D2 FACE=3D"Courier New">s low, across all =
the connections?&nbsp; We need to know if the number of Ops we can =
service changes dramatically if the load is spread</FONT> <FONT SIZE=3D2 =
FACE=3D"Courier New">across a lot of connections versus our normal tests =
with very few connections.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">7.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">In section 7.1, we probably should =
add a statement that we are not able to make sure that this many =
connections will work properly with LinkAggregation set up.&nbsp; While =
inn pra</FONT><FONT SIZE=3D2 FACE=3D"Courier New">ctice I would expect =
customers to use something to spread such a huge load around, we just =
don</FONT><FONT SIZE=3D2 FACE=3D"Courier New">&#8217;</FONT><FONT =
SIZE=3D2 FACE=3D"Courier New">t have the infrastructure to simulate that =
number of clients in a way that exercises LinkAggregation.&nbsp; This is =
probably more of a test about whether the switche</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New">s</FONT><FONT SIZE=3D2 FACE=3D"Courier New"> =
actually function properly anyways.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">Once you get all of this working in =
a networking sense we need to determine whether it works in practice =
with so many CIFS or NFS connections.&nbsp; If we could handle 1000 CIFS =
logons with Kerberos in 10 seconds(making t</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New">his number up for discussion purposes) then 32K =
CIFS connections is about 5 minutes and makes sense, but is 128K really =
achievable and across how much time would we have to spread the initial =
connects to avoid overloading the auth-agent?&nbsp; There is a =
simil</FONT><FONT SIZE=3D2 FACE=3D"Courier New">a</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New">r issue for NFS mounts with non-trivial export =
options (</FONT><FONT SIZE=3D2 FACE=3D"Courier New">NIS =
netgroups).&nbsp; While what you are proposing looks pretty complete =
from a networking (NCPU) layer, I think we need more on the =
CIFS/NFS/Auth-Agent layer changes that might be required to =
mak</FONT><FONT SIZE=3D2 FACE=3D"Courier New">e such a large number of =
connections actually usable.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C73CFB.12B9E766--
